This invention concerns the module chaining control in a modular software architecture located in an electronic unit with microprocessor. The invention is for example applicable to, but not limited to, electronic smartcards.
1. Field of the Invention
A modular software architecture comprises several modules defined according to the tasks they have to execute. While executing its tasks, each module can call other modules. These modules can be grouped in layers, and in this type of model, the modules of a higher layer generally call the modules of the layer immediately below to process some of the tasks they must perform. In practice, for example, in a software architecture for smartcard, all modules can be grouped in three main layers called the “core” layer interfacing directly with the hardware (in particular the processor, memories and input/output interfaces), the “system” layer concerning the operating system (OS) and the “application” layer concerning the various software applications.
To each module there corresponds a particular, well identified memory area grouping memory sections to store the corresponding program (non volatile memory), memory sections to store the data associated with this module (non volatile memory) and memory sections exclusively used by this program for its execution (volatile memory). A unique identifier designates both a module and the corresponding memory area.
When a module calls explicitly another module by an inter-module call, execution of the calling module program is followed by execution of the called module program. Any other form of chaining the execution of programs belonging to different modules is prohibited by hardware mechanisms.
It may be necessary, especially for security purposes, to only allow certain clearly specified modules to call a given module. For example, a certain module in the core layer accessing the data memory can only be called by a module in the system layer and never by a module in the application layer, or a module in the application layer can only be called by a particular module in the system layer and never by another module in the same layer. Equally, according to another example, a module in the application layer, since it acts as card administrator, can request services that the other modules in the same layer are not allowed to obtain.
In the context of this type of limitation, since a calling module can call any other module, it is the called module or an intermediate system between the calling module and the called module which applies a check of program chaining. Consequently, the called module or the intermediate system must be able to reliably and unambiguously identify the calling module. In addition, the behaviour of the called module can be determined and configured according to the identity of the calling module obtained.
The identification of the calling module is secured if:                firstly, it does not rely on the “good faith” of the calling module (i.e. the information concerning the identification of the calling module communicated by said calling module is checked); and        secondly, the identification mechanism is protected against modification attempts carried out by malicious software likely to produce incorrect identification of the calling module.        
2. Description of the Related Art
Software solutions to identify a calling module have already been proposed, in which a variable is used in the program to identify the active module. However, this purely software approach has certain disadvantages. Firstly, it is easily compromised, due to its purely software nature, by an impostor seeking to illegally benefit from the unauthorised resources either by modifying the identification variable in memory or by changing the program used to manage this variable. Secondly, with organisation in layers, although the operating system can easily identify applications since applications are run by said system, this is not the case for other identifications such as identification of modules in the operating system itself by the core: in this case, in fact, the information is not available.
The most common solution is to use cryptography to guarantee the identity declared by the calling module, i.e. use an authentication mechanism. However, in this case significant resources are required: a key known by the potentially called modules is required by each potentially calling module, as well as a cryptographic calculation for each call.
The invention concerns a method for secured identification of a calling module in a modular architecture which avoids the disadvantages described whilst remaining relatively simple.